1. The Field of the Invention
The present invention relates to computer network security, and more specifically, to mechanisms for generically deriving keys for use in encrypting, decrypting, and signing electronic messages.
2. Background and Relevant Art
Computer networks have enhanced our ability to communicate and access information by allowing one computer or device (hereinafter both referred to as a “computing system”) to communicate over a network with another computing system using electronic messages. In order for such electronic messaging to be meaningful, computing systems must process electronic messages in an appropriate manner. For example, an encrypted e-mail message must be decrypted using the proper decryption algorithm, then parsed into its various components (e.g., message body and “from”, “to”, “cc” and “time sent” header fields). If decryption or parsing are performed in an incorrect manner, the e-mail message would not be able to be displayed properly to a user.
Often, supplemental information is necessary or helpful in order to appropriately process an electronic message. For example, to appropriately encrypt or decrypt an electronic message, a computing system must have access to the appropriate secret code (frequently referred to as a “key”). It may be that a sending computing system encrypts an electronic message with an encryption key (e.g., a symmetric key or public key) and sends the encrypted electronic message to a receiving computer that attempts to decrypt the encrypted electronic message. However, the receiving computing system cannot decrypt the encrypted electronic message (and the encrypted electronic message will thus be essentially meaningless) if the receiving computer system does not have access to the appropriate decryption key (e.g., the symmetric key or a private key corresponding to the public key). Thus, computing systems will typically exchange a number of configuration parameters to establish these keys before any encrypted electronic messages are exchanged. This initial exchange of configuration parameters is often referred to as a “handshake.”
One example of a handshake is the Secure Sockets Layer (“SSL”) handshake sequence frequently used to establish a secure session between a client computing system (hereinafter referred to as a “client”) and a server computing system (hereinafter referred to as a “server”) on the Internet. An SSL handshake allows a server to authenticate itself to a client using public-key techniques and then allows the client and server to cooperate in the creation of session keys used for encryption, decryption, and tamper detection (signing) during the established session. An SSL handshake typically begins with the client and server exchanging information, such as, for example, SSL version number, cipher settings, random data, and other information needed for communication. During this initial exchange the server also sends a certificate to the client system.
The client performs a number of queries as to the trustworthiness of the certificate in order to authenticate the server. If the server is authenticated, the client can then generate a premaster secret for the session, encrypt the premaster secret with the server's public key (obtained from the certificate), and send the encrypted premaster secret to the server. The server uses its private key to decrypt the premaster secret, and then both the server and the client, starting with the premaster secret, perform a series of operations to generate the master secret.
Both the client and the server use the master secret to generate session keys, which are symmetric keys, used to encrypt and decrypt information exchanged during a subsequently established SSL session. The client sends a message to the server informing the server that future messages from the client will be encrypted with the session key. Likewise, the server sends a message to the client indicating that future messages from the server will be encrypted with the session key. After the SSL handshake sequence completes, the client and server exchange all encrypted data using the generated session keys.
However, a considerable amount of processing and data exchange must be performed (i.e., the entire SSL handshake sequence) before a secure session is established and any encrypted data can be transferred between the client and server. This processing and data exchange consumes both computer system and network bandwidth resources. Further, since SSL is a session-based protocol, the generated session keys are typically only valid for the duration of the established secure session. New session keys must be generated each time a new secure session is desired. Thus, if a client frequently requests secure connections of a very short duration, the consumption of computer system and network bandwidth resources can be quite substantial.
At times, it may also be desirable to generate new session keys for (or “re-key”) a session that has been established for a longer period of time. This re-keying is performed to ensure that the same session keys are not used for an extended period of time resulting in a potential security risk. Unfortunately, to re-key an SSL session the entire handshake sequence must be performed. Thus, even in long standing sessions, the SSL handshake process may need to be repeated with some regularity thereby further consuming computer system and network bandwidth resources.
Performing an SSL handshake to re-key an established secure connection can also cause older messages to be undecipherable and/or difficult to process as these older message may have been encrypted with a prior session key. Further, conventional mechanisms for generating session keys are not well suited for securely processing messages across multiple sets of endpoints (e.g., between three or more computing devices within a distributed system). For example, since SSL is session-based, the use of session keys generated for an SSL session is restricted to the computing devices involved in the SSL session (e.g., a client and a server).
Therefore systems, methods, computer program products, and data structures for more efficiently deriving keys used to securely process electronic messages would be advantageous. Systems, methods, computer program products, and data structures for generically deriving keys that can be used by multiple sets of endpoints would also be advantageous.